These last two weeks most of my time has been sucked into getting Python 2.5 as default into testing. That’s done now. I made use of the block uploads thingie ftpmaster implemented for the release team to use. Basically, if your package could disrupt an “almost there” transition, the upload will be rejected. The blocks were in place for 5 days, which I think it’s acceptable. As long as we don’t end blocking stuff for very long, I think we should be fine. See the end of this post for more about this. Though it was quite a bit of work, I’m very glad I took care it myself, since now I really feel I’m 100% back to Debian, after the time I spent off for health reasons. Update: Oh, and I forgot to say: having control over britney has really really helped. Thanks a lot Joerg for that.

---

Dudesconf Tomorrow I’m leaving to Coru a for Dudesconf, which is a kind of Debconf-ES. I’m giving an introductory talk to Git, a semi-lighting talk about grep-dctrl (30 min.), and (gasp) a talk about Debian packaging with a VCS. We may have a Debian Quiz as well. I’m so looking forward to it, since many people who’ll attend are amongst my most loved ones, and I already missed last year’s since I wasn’t fully recovered yet. See you there!

---

Minirok and Sevilla One of the reasons I wasn’t fully back to release management during the past 5 months or so is because I spent as much time as I had doing development for Minirok. I don’t think I mentioned here before, but I was participating in a Free Software Contest for college students organized by the University of Sevilla, Spain. Such effort finally paid off, since Minirok was elected as one of the finalists. This means next week I’ll go to Sevilla, to make a presentation of the project, and who knows what more. ;-) I’m very excited.

---

Finally, more on blocking uploads This Python 2.5 transition was the first time the block uploads feature was used, and there were a couple bumps along the way. In particular, a couple packages were blocked, when they shouldn’t have been (libqt4-ruby and evolution-sharp), and one needed package was not blocked, though Rene Engelhard thankfully spotted it very quickly (mono). The problem is it’s not completely straightforward to generate a list of all the stuff that could possibly affect the transition. What I did was to make a run of britney on an arch that had all the needed bits in place, and block all the packages that migrated together as a result of the hint. This fails in two ways:

• it can include stuff that is not needed for the transition, namely unrelated packages that happen to become candidates for testing by one of the their dependencies having migrated as part of the hint. This is what happened with libqt4-ruby and evolution-sharp.
• it can miss stuff that is needed, like packages that can migrate by themselves, so the main run prior to the hint migrates them, and hence do not show up as part of the hint, but that some package of the transition depend on. This is what happened with mono.

The second problem, though, can be fixed by parsing the excuses list and blocking stuff that some bits of the transition depends on. Easy enough. Yet, there are more cases when things can go wrong, for example a shlibs-bumping upload of a package (say, sqlite3) linked against by some package still needing a couple of builds (say, qt4-x11). For that, blocking uploads is not an option, since that’d be an insane amounts of packages that, furthermore, can be uploaded if they don’t bump shlibs, so I guess we’ll have to ask in the next release update that shlibs-bumping uploads are coordinated in -release too, at least when close to finishing a transition.

Yesterday I watched Les invasions barbares, a film by Canadian director Denys Arcand. I came to find it because one of my favourite cinemas in this oh-so-small city was premiering L’ ge des t n bres, the third part of a trilogy started by Le d clin de l’empire am ricain, and continued by Les invasions barbares above. I loved Les invasions barbares. I think it’s a very honest film, but for me not only it portrayed a reality and set of characters that I found credible, I also felt empowered by watching attitudes towards life so compatible, if not similar, to my own. Reminds me a bit of some of the feelings I had when watching Juno. It is also one film more to add to my (smallish) collection of films I’ve watched in French (with subtitles), though I’m intending to fix that: I really enjoy French, as well as enjoyed all Canadian or French I’ve watched in the past. We’ll see how it goes.

Sometimes, I’ll accidentally set my music player into “repeat track” or “repeat playlist” mode while working (my playlists are normally short, btw, one album or so). The funny bit is the number of times the track or playlist needs to be repeated in order to get me to notice. Not that many, but interesting nevertheless.

By pure chance I read somebody mentioning giggle in #git. It’s a visualizer for git branches written in C using GTK+. I find the output a bit nicer than that of gitk, at least on some repos. As Mike Hommey points out, though, it’s quite slow on medium and big repositories. P.S.: It’s packaged for Debian.

Unlike Martin and Daniel, please do call me by my IRC nick in real life, mostly because that’s what I’ve been called by everybody since I was 0. On writing the long version is ok.

I had never seen a prank upset so many people. On the other hand, almost 50 people (blindly?) said thanks!

I knew I liked to make my shell aliases short, but I wanted some statistics (FSVO “statistics”). With a simple pipe:

  % alias   sed -e 's/^alias //;s/=.*//;s/././g'   sort   uniq -c   sort -rn
       27 ....
       25 ...
       20 ..
       12 .
       11 .....
        7 ......
        6 ........
        4 .........
        2 .............
        2 .......
        1 ...................

This means 2-4 character aliases are the most common (surprise, surprise), followed by 1-character aliases, of which I have (oh god) 12. That’s 117 aliases total...

This is fairly obvious in theory, but it’s the kind of thing you don’t always think about: when receiving patches via e-mail, it’s possible to have Mutt directly color them as vim or colordiff(1) does. I have this:

  % grep rc_diff ~/.muttrc
  macro   index   \e,sd   ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
  macro   pager   \e,sd   ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
  % cat ~/.mutt/rc_diff
  color body brightblue default   '^\+.*'
  color body brightred default    '^-.*'
  color body brightgreen default  '^(--- \+\+\+) .*'
  color body brightyellow default '^@@ .*'

Update: In case there was some confusion, the rc_diff snippet above is meant to be sourced only when there’s a mail with a patch, otherwise it’ll highlight parts of normail email too. The way to disable again, though, is quitting Mutt...

Good: Probably because of its origins, there seems to be a higher willingness to write detailed commit messages in the Git community when necessary. I feel like at home. Bad: I really miss the distinction between mainline revisions and merged revisions. I guess that if they had that, there’d be less urges to rebase and squash all over the place.

I tend to favour text-mode applications (I’m sure vim, irssi, zsh and mutt account for most of my keystrokes, in that order), but there are times when a graphical application is called for, for example the browser. Or when I just find it more convenient, for example the music player. Lately, though, I’ve been pleasantly surprised by a couple graphical applications, for which I had text-mode versions which worked more or less acceptably: a random-note taker (I was using vim), and a dictionary (/usr/bin/dict). I’ve replaced these two with Lars’ Notetak, and StarDict. I’ve found that having them constantly running in desktop #2 (which is one keystroke away) beats having to start up vim or dict each time. Curiously enough, in both cases the main interface of the application is a text input line which offers some kind of “incremental search” functionality. StarDict is packaged in Debian (package name stardict-gtk or stardict-gnome), and Notetak, being Python, is easy enough to run from source (the page claims there is a Debian repository there, though I can’t access it).

Although Dato has recently talked about it, it is worth to drop again a few more bits about MyEpisodes.com as a try to increase its popcon among TV shows addicts. MyEpisodes.com is an easy way to track your activity watching TV shows. Using a fancy interface it is possible, for instance, to tag episodes as acquired/watched, be aware of upcoming premieres and, taking advantage of the provided RSS channels, stay up to date of new episodes without even visiting the website. Have you ever asked yourself how many hours have you spent in front of your screen watching TV shows? MyEpisodes.com has got the answer. Cool, isn’t it? ;)

Via Planet Warp, Blaxter blogs about MyEpisodes.com. Useful to keep track of your pending episodes to watch and acquire. I like the “All-In-One!” view. Update: Oh, and as several people mentioned, there is also pogdesign.co.uk/cat, but that’s only a calendar of upcoming episodes, you can’t track your status with it AFAICS. OTOH, it doesn’t require a login, only a cookie.

I’ll blush and admit that I’ve always been a bit of the “my package my castle” type. But things change, and now I feel differently about my packages. I toyed with the idea of adding myself to the low threshold NMU list, but it didn’t make me very happy for several motives:

• first and foremost, it places emphasis on the upload as the basic unit of collaboration, whereas I think such unit should be the commit
• places the information on a network location, whereas I think the information should be more readily available and near the package itself
• uses “non-maintainer upload” to describe itself, which is already something else

Then there is the collab-maint project in Alioth, which is nowadays intended as a general purpose area for small teams or groups of co-maintainers to collaborate in their packages, without needing to create a full-fledged Alioth project. Every DD and many non-DD have write access to it, but a package being there does not mean that its maintainers want other people to use such write access on their packages. But, alas, there is no standard way of saying that you do want people to make use of that access, and how (of such way could also benefit projects that make use of the Debian acl, to advertise the fact). So, as a first draft to fill in these gaps, I’ve migrated several packages of mine to the collab-maint umbrella, and added a X-Collab-Maint header to debian/control to signal that I’m open to collaborations on them. For me, a header felt the best way to express this information, since it ends up being very accessible (only one apt-cache showsrc away). As Zack points out to me, though, having it in a header doesn’t necessarily mean the source of the header has to be debian/control forever (think e.g. what debtags does) — this leads to interesting possibilities, like changing the policy without an upload, or setting the same policy for a large set of related packages. As for the contents of the header, I think a reduced vocabulary would work best. As a start, this is the one I’ve been using for my packages:

• commit-branch: please commit your stuff into a branch, so that I can review and merge it. Other people could just use commit if they prefer commits to trunk directly.
• upload-10: feel free to make an upload with your changes if I haven’t acked them within 10 days. Other people could use upload-with-ack, to signal that you’re happy for other people to upload, but that’d you like to review first. Or even upload-0.

Other stuff that’s could be specified includes whether people making a commit should notify the maintainer or not, before letting the upload day count tick. But, if the idea seems worth it, I’m sure we can debate it to death on -project, or something.

I uploaded amule 2.2.0~20080309-1 to experimental yesterday. It should fix the search-related crashes from 2.1.3, and be really close to the final 2.2.0 release.

At the moment I keep my packages in Bazaar branches. I only version the debian/ subdir (whereas I have the .bzr directory at the same level as debian, i.e. not debian/.bzr). I do that because then $VCS operations work without having to be under debian. One drawback is that the output of status is a bit too noisy, with lots of “unknown” files (all the upstream files). I address that by aliasing bzr std to “bzr status debian”. With git, one could just have the following:

  % cat .gitignore
  /*
  !/debian
  /debian/files
  ...

Update: One of the Bazaar guys, Wouter van Heyst, points out on IRC that bzr can do it as well:

  % cat .bzrignore
  RE:(?!debian/).*
  ./debian/files
  ...

In fact, possibly more: lines starting with RE: are interpreted as Python regular expressions.

So I was impatient enough and took a stab at writing a bzr frontend for git-fast-import(1). (By the way, the idea behind git-fast-import rocks, and is being adopted by other projects, e.g. bzr-fastimport.) I announced it here, and for now it lives in:

http://chistera.yi.org/~adeodato/tmp/other/bzr-fast-export.git

1. Bzr Exactly 2 years ago I started using bzr. I wanted to start using one of the new distributed VCS for my small projects, and I chose bzr. Not having the time/energy to do an exhaustive comparison among them and try them all to see which one I liked most, I read some articles about them, and decided that bzr would be the most appropriate for me, and that I’d stick to it if I was satisfied enough. (JFTR, at that time it was very important for me the ability to serve branches over plain HTTP, and bzr was the only one in which HTTP was a first-class citizen.) I’ve found bzr easy to use and to learn, powerful enough, customizable enough via plugins, and in general, not requiring a whole lot of attention to get things done. Also, not slow enough as to abandon it. 2. Git Yesterday somebody posted in #bzr a link to this post by Elijah Newren, where one comment said:

There’s one thing I keep telling people though: Learning git is like learning vi — it’s different from the VCS/text editors you know on a fundamental level. But once you’ve overcome that problem, you’ll not want to go back. Ever.

Which pretty much matched the idea I had of git. In the summer after my first year at Uni, I told myself: “OK, let’s learn vim.” And I think it’s one of the decisions that has paid off the most. Like learning to touch type. Reading the above quoted paragraph made more urgent the doubts I had been sporadically having during the past year: maybe I would have been better served by choosing Git instead of Bzr in the first place. What would be my life like if I had stayed with joe? 3. More about Git So yesterday I decided to spend a couple hours (or three) getting the feel of it, trying to find cool stuff. Until now, whenever I had had the need to use git, I just sticked to the bare minimum, without diving into it. I’m going to mention only two examples of the cool stuff I found. And I’ll confirm that, in my opinion, the comparison to vi really holds.

1. commands have lots of options. Tons. And some are incredibly cool, for example git log -S. It allows you to show entries whose diff contains the given string (or pattern, with --pickaxe-regex). I was missing bzr’s log --message, but it was obviously there, as log --grep.
2. Elijah has another entry that talks about what he dubs the “libmo”, and how it’s different between git and the rest, because of the “index is not automatic” schema. In particular, that entry opened my eyes about one very useful use of the index: putting there parts of an upcoming commit that are known to be correct, and that need no further inspection. Doing that with git add -p makes those parts no longer appear in your git diff, which is... whoa. I like to review before committing a lot. However, with other VCSen I always find myself reviewing/glancing at the same parts over and over. So having a way to review what’s pending or WIP is something to die for. And I know even before getting addicted to it!

4. More about Bzr I’m not sure I want to completely switch from bzr to git, not yet anyway. However, I think I’ll try it for some new projects, or migrate some minor ones. Before I can migrate everything I’ll need a bzr frontend for git-fast-import. One of the bzr authors, Ian Clatworthy, has written bzr-fastimport, and he tells me a simple exporter would not be very hard to write, and that he may even put some work into it. Also, I’m (still?) not very sold with some of the git standard practice of throwing away parts of your history regularly. We’ll see about that. Finally, one feature of bzr I would love to see in git is indented formatting for non-mainline revisions in log output (for git, in --topo-order mode only). This is most needed when you’re not rewriting your history for submission to mainline, I’ll reckon. Compare —date-order to —topo-sort to —topo-sort with —indent. Update: For this —indent thing, one could use tig, which after pressing g offers a sort of tree view in a curses-based interfaces. Somebody had mentioned this on IRC, and Peter Baumann kindly mentioned again over e-mail after reading this entry.

I’ve decided to blog about films whenever there are in my backlog five films I’d like to mention or talk about. I’ll also mention that when I moved to ikiwiki, I set up a films.rss feed, and some other stuff. Now:

• A History of Violence: short and incredible. Has flaws but I still give it 4.5/5. I’ll check more of Cronenberg (I loved, ages ago, M. Butterfly and Dead Ringers).
• Bent: gays, nazis, camp. Intense but not overly rough. Mick Jagger plays a drag singer named Greta.
• Elsa y Fred: terrific love story between two elderly people. Magnificent China Zorrilla. Ignore if you can’t stand romance or Argentinian.
• Martian Child: entertaining, has children and dogs, never ever ever ever ever give up.
• No Country for Old Men: oooh. All my friends hated it and told me: “you are going to love it”. And Bardem really steals the show. More below.

---

You may want to skip this part if you haven’t seen No Country for Old Men, though I won’t be spoiling much. My friends watched it some weeks ago, and I did yesterday (I refused to go with them to a dubbed session). One of them told me that she had disliked it very much because of the uneasiness she got from it, about how human life can result so worthless for people, and so on. Chatting a bit more, we came to the conclusion that I watch these films differently. Basically, I can unplug the empathy off from a film whenever (simplifying a bit) violence or cruelty reaches a certain level, and just consider it an entertainment completely unrelated to reality. Sort of, anyway. And I don’t think I could enjoy (some) films as much if I didn’t. For me, No Country for Old Men had no message in it, and had a single story line: following close the path of a creature portrayed by Bardem, that (maybe not) strangely enough managed to keep me hooked to the screen, not minding the low pace, and finding the end (minus the dreaming bits) very appropriate.

I use the enhanced commentify script from vim.org to easily comment and decomment parts of code. It knows about comment delimiters in a ton of languages, and it’s generally nice. Lately, I’ve been a bit annoyed about commenting several lines with different indent levels. In particular, given for example this snippet:

  def foo():
      if duck.is_hungry():
          grab_food()
          feed_duck()

If one instructs the script to comment the three last lines, the result is:

  def foo():
      # if duck.is_hungry():
          # grab_food()
          # feed_duck()

When what I would like is:

  def foo():
      # if duck.is_hungry():
      #     grab_food()
      #     feed_duck()

There is one variable one can set to achieve this behavior: EnhCommentifyUseBlockIndent. However, it only works when commenting from visual mode. From normal mode (what I normally use — that is, going to e.g. line 2 above, and pressing 3,c), it doesn’t work, because from normal mode the commenting function does not receive the block, it just gets called three times, once per line. To solve this, the solution I found was to create a custom command that accepts a range, and calls the function exactly once, for the whole block. In particular, this is all my enhanced commentify configuration from ~/.vimrc:

  let EnhCommentifyPretty = "yes"
  let EnhCommentifyUserBindings = "yes"
  let EnhCommentifyRespectIndent = "yes"
  let EnhCommentifyUseBlockIndent = "yes"
  " The MyEnhancedCommentify bit is needed because the normal nmap just
  " calls EnhancedCommentify() <count> times, thus UseBlockIndent can't
  " work.
  nmap <Leader>c :MyEnhancedCommentify<CR>
  vmap <Leader>c <Plug>VisualTraditional
  command! -range MyEnhancedCommentify 
      \ call EnhancedCommentify('', 'guess', <line1>, <line2>)

Adeodato correctly points out that building under a Sarge chroot, and expecting the package to work on Sid, might not always[1][2] work mainly because of ABI changes and similar changes. Thus, I am forced to clarify this a little.


Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.


So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.

Thanks Adeodato for the heads-up.

[1] unless your package is a special case
[2] or, better said, in most cases

---

udate: fixed the link to dato's post